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to take advantage of lessons learned from the Apollo CSM and LM iGXCS software 
activities. Before becoming encumbered -with the present plans for such future 
•computers, such as those for the "space shuttle", a list of desirable design 
features for such a device has been assembled below. Lacking any details of how 
the computer will fit into the spacecraft design, and indeed what the system design 
will require (page 17 of Aviation Week for 19 January 1970 indicates that CX5X 
is to issue RFPs on 21 February for this purpose), the general Apollo-class of 
activity has been assumed. 

No attempt is made to assign functions to the computer hardware as opposed to 
supporting software, since these decisions require knowledge of relative costs of 
each approach (the AGC analogy would oe a requi.reir.ent ior "double precision vector 
cross products", which of course is in the software of the interpretive language, 
although a programmer can essentially treat the VXV operation as a "hardware" 
capability j • 
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From the viewpoint of Apollo background, design characteristics of a future 

airborne computer should include the following (in roughly decreasing priority); 

1. Ample erasable memory 

One of the major causes of software difficulty in Apollo has been a limited 
amount of erasable memory. This has caused difficulties in a variety of areas 
(even such situations as use of R31 with MIDFLAG set), and is prooably a major 
obstacle to the realization of the full advantages of higher-level program 
languages. Manual assignment Qu. variab-i.es oo particular cells, and mcai.i icatio**o, 
requires a vast amount, of knowledge as to the design of the complete program, C 
hence a high skill-level and considerable experience on the part of the people 
involved. 

This is a good example of the hardw r are/software conflicts that can arise, since 
erasable memory requires more volume, more power, and imposes heat dissipation . 
problems considerably in excess of those for fixed memory. Thermal operating 
regions can also be stricter, and reliability assessments would favor a given 
amount of fixed memory over a somewhat lesser amount of erasable memory. One 
possibility would be to- have about naif the memory be iixed, and the other 
half optionally be used for variables or program steps (this is done in the 
AGS from a packaging, heat, and power consumption viewpoint, and. hasn't been 
too drastic a constraint, in spite of the "very fixed" nature of "fixed" .memory) • 


2. Floating point capability 


Although the number of post-release problems 


in Apollo software due to scaling 


difficulties has not been large, the amount ol manual analysis ana cneeKing 


that 


must be done to insure that scaling problems are avoided has been 


considerable (and for unanticipat 


ms. overilow can cause aiiiicuities 


that might be avoided if floating point were used). As observed by F. Clark 
of TRW when discussing future computers, "i wonder if they will decide that 


floating point is here to stay yet. 

Floating point is another good example of hardware/software conflict,, since 
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case in Aoollo where floating point would have been useful was for measurement 
incorporation of the rendezvous radar rate data Program performance study 
led to the inclusion of a "quasi-floating point' normalization in tn^ area 
with a subsequent improvement in software performance. In generc , * f f 

ooint does not "improve accuracy",' however, since the consumed to specify 

the location of the "binary point" could be usea to good advantage to prov-ac 
additiofaiprecision for ^operand. Next to erasable memory determination 
by some automatic means of proper scaling for quantises is P^babiy the ma,o 
obstacle to the use of higher-level program languages, Automatic scheme- can 
he dreamed un of course, but whether they always compute (.A-i d t m 

the oro^r o?der, for example, to avoid overflow isn't so clear, especially 
if 3’and C are always negative and A and D positive: snouio not reariun^e Uv 

3 . Sufficient fixed memory' 

A limit on fixed memory is, from the point of view of a software manager, a 
very desirable thing, since this puts an upper bound on the amount of wo.k 
that has to be done, and helps drive home to his customer that the _ °°®P“-tei 
can do anything but not everything". Sizing of fixed memory is unooubtedly 
a rough job, and applications for fixed memory probably will grow until the 
memory is filled (exclusion of P37 "inside the sphere" in the CSM is a good 
example of something nice to have for Apollo that we aon t ha ^ e ° f 

memory problems). Probably the best arrangement is some sort of ability 
to add additional memory modules as new requirements become identifie^. 
some extent, this capability is in the AGC due to the unused values 0 
SUPERBNK, but this approach restricts somewhat the "rancor^ access cap b ty, 

, thus relegating relatively independent functions (sucn as Pxnball) to the 

orohan banks of memory. In the picturesque vocaoulary of one MbC inaav.au_}, 
the "software becomes the garbage can for all the hardware's problem, , and 
•ohis tendency presumably will be true in the future. 

4 . Moderate execution time 

For the sake of preflight validation (and such applications as crew trainers), 
the execution time capabilities of the computer should not be ' 

a factor of no more than 6, for example, improvement over Apollo (givin 
an add time of 4 microseconds or more) should be tolerated. Thxs may allow 
serial as oooosed to parallel arithmetic (saving hardware), and in any case 
SdiSs circuit epeedi with , galr. in „U,bilitj ^ruffi.dncss") 
byproduct. The software cost reduction here is similar to that gained un 
item 3 by "sufficient" (as opposed to "ampie") fixed memory: by reducin„ the 
-7 amount of activity that needs to be going on in the_computer more attentio 
. can be paid to that which remains, and proper decisions can be made on what 
is really needed vs. what is done because it doesn t cost anything . 

. Restrained interrupt structure 

Arrival of interrupts at unexpected times has caused AGC softwareJ^do^link 
•i-n the cast such as the "ghost" R3c at ignition ana some unbuffered downlink 
information* forradar data®!* the IK. In addition, of course there was the 
counter interrupt "overload", leading to renewed emphasis on ^ust 
fiw much 0 f a ^LOSS safety factor should be reflected in the onooard software 

This area too is a haniware/software conflict, but of a slightly-afferent 


type than som 


of the others. Here, software in some sense is maae 




by so von. 1 different, interrupts (four based on time, for ex.-miplo, rfmrena ■ 
one, except perhaps for 10 ms phasing and least increment considerations, might . 
javo been enough), but possible "sneak paths" are compounded too. It seems 
mandatory that some sort of synchronism to real time (other than by equalization 
ox computing delays for different program branches) be available similar to . 
ne ^ war oust" capability in the AGC now. Whether this is some periodic 
?v en Kp UCh as the AG ^ 20 ms interrupt or a more elaborate'variable delay as in 
the AuG now is a hardware option. Telemetry and manual inputs could be keyed 

on ox this interrupts is done now in AGC for the LM thruster fail inputs 
for example). 3 

If counter interrupts are continued, a method should be available to have the 
so^oware disable them (as seems to be provided, although not used, for the 
uplinx oy bit o of channel 13). A nagging problem in software validation is 
that ca f not P^dict before the flight the exact sequence in which the program 
computations vo.ll be executed during flight (i.e. just when the display 
interface routines will be entered with respect to when a PRO response to flash fo 
engine ignition^was supplied;, and counter interrupts are certainly a contributor 
"0 I,nls uncer '^ a inty. . Due to the hardware savings which they can achieve, 
however,•perhaps their continued use is justified. 

6. Flexible input/output capability 

As part, perhaps, of the "garbage can syndrome", it is natural that additional 
interlaces lor tne computer will become identified as the flight program 
progresses.. One interface that was handled easily was the PRO button (which 
m an ^original" design might have been another key code, but for ease in 
retro-fit was made^a contact closure), and another one, not handled so nicely 
was -che addition of a rate display capability on the FDAI in the LM: it would* 

.nave been desirable to drive the separate rate needles directly, so that, 
boon^rate and attitude error displays could be provided. A degree of flexibility 
-n une yO would also help to dispose of space surplus computers for applications 
in wmch tneir fixed memory is not a disadvantage. 

Cr.-w possioiiity for doing this would be a separately packaged I/O unit, 
connected to the computer "mam frame" by a restricted number of lines If 
this approach had been in use in Apollo, the channel 13 "stall" routine, which ' 
can roo as much as 5 ms of execution time, perhaps could have been implemented • 
more easily in the hardware (although this particular problem, of course, in 
retrospect should have been handled by an interconnection spec). 

7. Input/output override capability 

w hardware capability that might simplify the software job is an input/output 


vuxiici-duic vo xedixures ox tne interlace (.such as the 
stuck.mark Dutton before H2 over-riding the ROD input,or a improper RR Auto 
mode input keeping the Apollo 11 descent problem from being avoided). These 
items. perhaps special cases of the general philosophy of "give the user/ 
programmer control over the machine if he wants to use it." 


some software design before freezing the hardware 


evidence onat tms was done for the --i.poa.lo computers is one of the most 
impressive features of the PGNCS design. The EDO? register, for example, 

• which shifts bits 14-8 to bits ?-l, probably was included solely for use 
with the interpretive language, where it saves execution time over performanc 
of a similar function by order code means, although it also has been handy 
since the transition to decimal verbs and nouns. Whether a special purpose 
register such as this is included in NACA (Next Airborne Computer Attributes) 
hardware or not isn’t a question that can be decided now: the philosophy that 
led to having this register in the AGC design, however, is one that must be 
encouraged. The alternative of a jazzy hardware-design regardless of the 
software headaches (such as the Air Force Titan II computer that saved a 
diode for a price of hellish divide) cannot be allowed’to prevail. 

Consider the problem of in-hardware program debugging 

Regardless of the general purpose computer simulations that may be made, 
problems will probably still be found only after the program is running on 

'the actual hardware. These have proven at times to be extremely difficult 
to track down (such as a peculiar Executive System difficulty in an early 
LM-1 program release or, perhaps, one of the R3o "ghost" appearances in 
more recent programs). For the AGC, a special hardware unit ("Prbject 
Trace" in early 1968 ) perhaps has been obtained, but perhaps for future 
systems a penalty in software proficiency should be paid for the sake of 
easier debugging later (whatever happened to that V33 flash in the CMS entry 

• simulations in late October '1969, by the way?). 

Avoid excessive software burden due to restarts • 

If restarts are felt to be a consideration for NACA, then the burden of 
recovery from them should be removed from the software. This item probably 
belongs earlier on the priority list than here, in view of the amount of 
special programming effort that has to be spent (even for such "elementary" 

’ actions as decrementing velocity-to-be-gained by accelerometer outputs) in 
allowing for restarts and recovering from them, the difficulty of systematic 
testing,and the number of post-release difficulties that have been discovered 
One approach might be to forget about them, since proper programming to hand! 
them seems another area making use- of higher-level languages less beneficial 
than might otherwise be the case. 

Other items . . 


As merely a sort of checklist, the following items should also be considered 
in evolving the design of a future airborne computer: • 

a) Crew training techniques 

b) Crew interface/override requirements 

c) Mission-critical computer actions (e.g. burns or aborts) 

cl j Soitware managemeno procedures ^ s6<- — g ~ ^j^.e j 

e) Software validation procedures 

f) Soft-ware documentation 

g) Programming language to be used (or imposed) 


